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chapter 1 


INTRODUCTION 

1.1 MOTIVATION 

Since the inception of the digital computers, with 
their symbols as zeroes and ones, there has been a continual 
thrust on bridging the communication gap between human 
beings and the machines. Over the last two decades, signi- ; 
ficant steps have been taken in this direction, which 
includes the development of a large number of programming 
languages, based on Chomsky's context-f ree-grammers . These 

i 

formal languages though, can be easily automated, are not ; 
compatible with human languages of communication. Till 
today, the human skills of understanding and expression of 
natural languages, are considered to be challenging problems 
in artificial intelligence. 

The human ability to translate amongst different 
languages, is one of the very interesting problems in the 
area of natural language processing. All over the world, a 
large number of attempts have been made to mechanize the 
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process of translation. The machine translation project at 
I . I .T. (Kanpur )is one such attempt. The goal of the machine 
translation project is to achieve automated translation 
accross 14 different Indian languages. 

There are mainly three different approaches to machine 
translation : 

1. Direct approach: In this approach, for every pair of 

source and target language there is one dedicated trans- 
lator. In the present context such an approach will need 
construction of large number of translators . 

3. Intermediate approach: The intermediate approach is 
characterized by the intermediate language of represen- 
tation. There exists a mapping from the source language 
to the interlingua and the interlingua to the target 
language. 

2. Transfer approach: This approach lies somewhere between 

the above two approaches. 

The machine translation project has adapted the inter- 
mediate appproach- Uith the intermediate approach one can 
achieve portability and modularity of design. In the worst 
case 14 different analyzers and 14 different synthesizers 
are needed. The intermediate language of representation is 
Conceptual Graphs (appendix 3). 
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The process of translation has to go through two dif- 
ferent phases. In the fist phase, the analyzer, called the 
parser, which analyzes the source language text to produce 
the intermediate representation. In the second phase, the 
generator, generates from this intermediate representation a 
text in the target language. The problem of text generation 
appears to be particularly challenging, when one takes a 
careful look at the numerous complex processes involved. 


The principal motive of this thesis is to explore the 
problem of text generation in the context of machine trans- 
lation. 


1.2 THE PROBLEM 

The natural language generation involves a careful con- 
sideration of some issues like, 

1. The style of representation in the text. 

2. The relative ordering of the information by which the 

empahasis and the form of the text are related. 

3. Syntactic constructions, conveying the mood of the text. 

4. Surface structures which are important for complex and 


compound sentences. 
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5. Supressing the redundant information when it can be 
inf erred . 

Given the scenario that the analyzer part of the translator 
(viz, the parser) analyzes the source language text 
correctly, the information regarding the style, relative 
ordering of information, syntactic constructions etc., is 
correctly carried over from the source language to the 
intermediate language, and that the generator synthesizes 
the target language text from the output of the parser, the 
complexion of the problem changes somewhat. Since most of 
the traditional problems of language generation, as men- 
tioned above, are solved by the analyzer and the relevant 
information is carried over to the intermediate language, 
the generator can directly utilize this information. 

In the given context however, there are certain other 
problems which are more important. A given concept may have 
one or more than one realizations, in the target language. 
Such a situation can arise due to a several synonyms or 
closely related words in meanings. This problem of lexical 
choice has to be handled by the generator by making the most 
appropriate choice regarding the lexical entry. 

Sometimes, the target language may have a special dev- 
ice for expressing a certain piece of information. Or the 
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form of the sentence under consideration may have to under£o 
certain changes. These idiosyncraci es of the languages have 
to be carefully dealt with by the generator. 


Another problem, very typical of this system is that, 
the parser and the generator are supposed to use the same 
data pool . Hence the generator should try to convert the 
data to it’s required form. Uithout any additional burden 
on the language experts for creation of different data for 
the generator. 

In a translation system, more often than not the data 
is likely to be incomplete due to its sheer size. To make 
the system robust enough to deal with this reality, the gen- 
erator should exibit a graceful degradation, when dealing 
with incomplete data. 


1.3 CONTRIBUTIONS 


takes 
erat es 


generator has been designed and 
an intermediate repesentat ion as 
the target language text. It deals 


implemented that 
its input and gen- 
with the problems 


outlined earlier, in the ways described below: 
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(i) lexical choice : 

It chooses words in the target language for a given con- 
cept if available from the concept diet ionary(target 
language dependent). However, it can also make use of 
the information that a concept has a better lexical 
realisation either higher up (less specific) or lower 
down (more specific) in the concept type hierarchy. If 
more than one choices exist, the most appropriate choice 
is selected using symbiotic constraint satisfaction 
(chapter 3, section 5) ,ie, the lexical choices of the 
arguments of an action concept govern the lexical choice 
of the action concept itself and vice versa. 

(ii) handling language idiosyncracy : 

A transfer approach is taken to solve this problem. The 
intermediate representation passed to the generator is 
transformed to a form which is more compatible to the 
target language. A transfer specification syntax has 
been developed using which, the language expert can, 
with minimal effort, express the transfer rules for a 
language. 

(ill) no extra onus on the languange expert : 

An interface package has been developed which operates 
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on the data supplied by the language expert and gen- 
erates all the data structures the generator requires. 

No separate data is needed to be prepared manually for 
the generator. 

(iv) dealing with incomplete data: 

This has been implemented for the data embodying the 
concept-type to lexical choice mapping. When a concept 
type has no lexical realisation in the concept diction- 
ary, its type definition (Sowa, ’84), containing less | 
specific concepts, is invoked. 

While designing the generator, the main aim was to 
maintain the structural layout of the parser while reversing 

I 

the function of each component. That is, the relationship 
between the input and the output of a particular generator 
component is sought to be the same as that between the out- 
put and input of the corresponding parser component. 

I 

1.4 OUTLINE OF THE THESIS ; 

. 

Chapter 2 presents the Machine Translation system to 
provide the context in which the generator fits in. 



Chapter 3 describes the transfer phase which perforins 
both lexical choice and graph transfer. 

Chapeter 4 talks about the rest of the phases of the 
generator - 

Chapter 5 gives a limitations of this thesis and scope 
for future work. 

Appendix 1 contains a few sample runs from the opera- 
tional system . Appendix 2 contains input and output at 
every stage of the generator. Appendix 3 gives a brief 
introduction to conceptual graphs. 
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chapter 2 


OVERVIEW OF THE MT SYSTEM 


2.1 A BIRD’S EYE VIEW 


> TL 
strini 


fig. 2.1 THE MT SYSTEM 

(SL= source language, TL= target language) 

The approach adopted for translaton in the MT project 
at IITK involves usage of an intermediate representation, 
viz conceptual Graphs (CG). The source language text is 
analyzed by a parser which expresses the information content 
of the text in an intermediate form(CG), and from that, the 
target text is synthesized by a generator. The parser and 
the generator access language dependent data (which they 
share) and are themselves independent of the language to 
which they are applied. 


I 1 INTERMEDIATE | | 

SL ==>1 PARSER |==> REPR. ==> | GENERATOR | == 

string II 11 



2.2 UHY INTERLINGUA 


Having an intermediate representation has many advan- 
tages. Firstly, with a direct approach of translation (ie, 
one translator for every language pair) across N languages, 
N*CN-1) differrent translators would be needed , whereas in 
this case one needs N parsers and N generators only. 
Further, since the programs depend on no specific language, 
one parser-generator pair with N blocks of data (one for 
each language) would suffice. This approach also has a very 
important by-product in that it lends powerful insight into 
the interesting devices that languages use to handle various 
natural situations. Questions as to how similar or dissimi- 
lar the devices are, why so, whether the similarities can be 
extended to a formal model of understanding etc. come up and 
are at least partially answered- An obvious disadvantage of 
having an intermediate r epresentat ion is that it rules out 
adoption of any ad-hoc-isro for phenomena peculiar to a cer- 
tain language pair - something which is frequently done and 
is perfectly feasible in the direct approach. But that's the 
price one pays for having a clean, tanguage independent 


model , 
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2.3 UHY CONCEPTUAL GRAPHS 

The notational ’'naturalness” of conceptual graphs makes 
it a very appealing method of knowledge representation for 
natural language processing. Also, since it has a direct 
mapping to first order logic with equality and modal logics 
(if embedded contexts are used), an inference mechanism can 
be incorporated with it. This would allow the usage of a 
knowledge base in disambiguating source language sentences 
in the KT system. It would also be possible to extend the 
usage of this system to contexts other than translation, 
viz, natural language understanding. 

2.4 THE DATA PATH 


SL ==>| PARSER |==> (CG) ==> | GENERATOR | ==> TL 
string II II string 

4 i 

(DATA FOR PARSER) (DATA FOR GENERATOR) 

I I 

■* INTFC > 

f 

LANGUAGE EXPERT 

fig. 2. 2 THE DATA PATH 



10 


Interaction of the language expert with the MT system 
shown in fig. 2. 2. S/he would be expected to provide all 
the relevant data about a language (say LI) and the INTFC 

Vv T 

•i^ock would generate the data structures for the parser and 
the generator (Lip and Llg) separately. The need to generate 
two sets of data arises largely from access efficiency con- 
siderations, since the two arms of the translator use the 
same data from different viewpoints. Therefore, the data 
^sed by the parser and the generator are identical in con- 
tent but dissimilar in organisation. The basic premise that 
the usage of data is arm independent still holds. 


For translating from LI to L2 , the scheme in fig 2.3 
vould apply. In order to translate from L2 to LI, one would | 
simply need to replace Lip by L2p and L2g with Llg. j 


SL(L1)==> I PARSER I 
string I I 


f 

(Lip) 


> (CG) = = > I GENERATOR I = = > TL(L2) 

I 1 string; 


(L2g) 


fig. 2. 3 TRANSLATING FROM 
LI to L2 
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2.5 A BRIEF LOOK AT THE PARSER 


CONCEPTUAL 

GRAPH 


1 1 

1 PARSER 1 

< - - 

KARAK CHARTS 

1 CORE 1 


NOUN CHARTS 

4 

1 LIST 

OF 


lUORD GROUPS 


1 

1 GROUPER 

1 

1 <-=-=- 

TRANSITION 

1 

1 

NETS 

♦ 

1 LIST 

OF 


1 UORD 

ENTRIES 


1 

1 MORPH. 

1 

= LEXICON 

1 ANALYZER 

1 



I 


SL TEXT 

fig. 2.4 THE PARSER 

2.5.1 The morphological analyzer 

This block accesses the lexicon to look up all possible 
lexical entries for every word in the incoming text. Uords 
are stored a.s tries for prefix sharing. Postfix sharing is 
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accomplished using end-tries. The corresponding piece of 
data for the generator is organised differently to facili- 
tate efficient access of a word form given a lexical entry. 

2.5.2 The grouper 

This block uses transition nets to group lexical 
entries correctly (by using conditions on the arcs of the 
net) and returns a word group entry each time a group Is 
successfully identified (by using actions at the states of 
the net). Implausible lexical entries for a word form are 
evidently eliminated by this block. Once again, the 
corresponding block in the generator, viz, the splitter does 
not use transition nets but a table lookup. 

2.5.3 The parser 

This block uses karak charts and noun charts (schema 
described in the next chapter) to inspect the selectional 
restrictions (yogyata) and demands (akankshya) of word groups 
and assigns semantic roles to them. Given more than one 
meaning of a word (expressed in a word group) it identifies 


I 
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the correct sense by applying selectional constraints 
(specified in the schemata) on the potential source groups 
of a demand group. Disambiguating the sense is synonymous to 
identifying the concept a word group corresponds to. These 
concepts connected together with the relations (which are 
the identified roles) results in the final output, i.e., the 
conceptual graph. The corresponding block in the generator 
shares the schema completely but accesses them from a con- 
cept dictionary (3.1.1) containing the mapping of concepts 
to lexical entries for the target language. 

2.6 ROUNDING UP 

Often, devices for expressing a given situation vary 
across languages and taking care of such idiosyncraci es may 
be accomplished by transforming the CG to a new one from 
which the closest target language sentence would be comfort- 
ably generated. For this end, a transfer component is used 
which also accesses language dependent information. 
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CG FROM 
PARSER 
I 

t 


I TRANSFER | 
I COMPONENT I 


I TRANSFORMED 
t CG 


I I 

I GENERATOR | 
I CORE I 


I LIST OF 
t WORD GROUPS 


1 SPLITTER I 


1 LIST OF 
t WORD ENTRIES 


I MORPH. 1 
1 SYNTHESIZER 1 


t 

TL TEXT 


fig. 2.5 THE GENERATOR 


It is not difficult to imagine the need for a similar 


block 


just after the parser-core for cases when most of the 
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languages have similar difficulty in expressing a given 
situation. Then, the parser’s transfer component would 
affect the relevant change on the CG before passing it on to 
the generator- The final structure of the generator is 
shown in fig. 2. 5. Each of the components are described in 


detail in the forthcoming chapters. 
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chapter- 3 


THE TRANSFER COMPONENT 


I CG from the 
I PARSER 
I 

I 

!<==== CONCEPT DICTIONARY 
1 
I 

I target lang. 

I compatible + 

I lexically bound CG 
1 to the GENERATOR 

fig. THE XFER COMPONENT 

This block plays a key role in language generation in 
the present context ,viz, machine translation. Its task is 
essentially twofold, 

(a) to alter the input CG : 

This is done in order to handle language idiosyncraci- 
es . Often, the target language(TL) in question has a 
special way of expressing the information embodied in 


TRANSFER 

COMPONENT 
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the input CG. In such cases, the closest(to human 
translation) TL sentence cannot be e^i^er-ated by operat- 
ing the generator directly on the output o£ the parser. 
Our solution is to make use of the knowledge about the 
idiosyncracy and to transform the CG before handing it 
to the generator. A situation where such a transforma- 
tion is needed is described below: 

Supposing we are to translate from Hindi to Telugu and 
the sentence is, 

rAma ne sadaka para eka GadI pAi 
ram on road one watch found 

(ram found a watch on the road) 

The output of the parser looks like: 

[pA-2]- 

(karta)-> [manuRya : rAma] 

(karma )-> [GadI-1 ] 

(desh-adhi )-> [ sadaka- 2 ] 

(tam)-> [yA] . 

The corresponding sentence in Telugu, expressing the 
same information, does not have an active construction. 



18 


So, the CG has to undergo a passivisation. This partic- 
ular transformation is not desired for each and every 
instance of usage of the verb "find” but only when the 
fillers of the semantic roles of the verb satisfy cer- 
tain conditions C 3 . 1 . 4 . 1 ) . The action( 3 . 1 . 4 . 2 ) associated 
with the transformation here, involves altering the 
roles of certain arguments of the verb, viz, 
karta--> sampradaan 
karma--> karta 

So, the output of the xfer component needs to be: 

[pA-23- 

( sampradaan ) - > [ manuRya : r Ama ] 
(karta)->[GadI-l] 

(desh-adhi )-> [ sadaka-2 ] 

(tam)->[yA] . 

(b) to make a lexical decision about each of the concepts in 
the graph: 

A concept may or may not have a lexical realisation in 
the target language. If it does, there may be one or 
more choices. In the latter case, the most appropriate 
choice needs to be identified. If no choice exists, the 
concept may be realised using either its type 
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de f ini t i on (Sowa , ’84) or another concept related to it 

by hierarchical dependency. As an example of the latter, 
supposing ve are to translate from Bengali to Hindi and 
the sentence is: 

rAma jala KAcCe 

ram water is-drinking 

(ram is drinking water) 

The output of the parser is: 

[KA-0]- 

( t am ) - > [ yA_r ahA_hE ] 

Ckarta)-> [manuRya : rAm] 

( kar ma ) - > [ pAn I ] . 

The concept KA-0, which can be equated to the English 
’’ingest”, has no realisation in Hindi. However, KA-0 
does have many subtypes in the concept type hierarchy 
for action concepts, one of which is pI-2 , whose selec- 
tonal restrictions on the arguments (viz , karta, karma 
etc.) is satisfied by the CG. So, the concept KA-0 in 
the CG is lexically bound to the choice corresponding to 
the concept type pI-2 in the concept dictionary(3 . 1 ) . 
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3.1 CONCEPT DICTIONARY (CDict) 

This is a language dependent database organised as fol- 
lows : 

key: concept type 

value: (<lexical category> <lex. choices> <transfer 
rule> <lex, sped f icat ion> ) 

3.1.1 DESCRIBING THE CONTENTS OF A CDICT ENTRY 

(i) lexical category : Fillers for this slot are the 
usual categories, eg, noun, verb etc. 

(ii) lexical choices : This feature takes a list of 
lexical entries (possibly empty), each of which are organ- 
ised as a C<root> <schemata>) pair. The schema for action 
concepts are called karak charts ( 3 . 1 . 2 ) and those for the 
arguments ( 3 . 1 . 3 ) are called noun charts. Only pointers to 
the schema are stored here since more than one concept types 
often use the same schemata. 

(iii) transfer rule : This slot is either empty (if no 
tranfer needed for the concept type) or contains a transfer 
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specification in a syntax described in 3.1.4. 

(iv) lexical specification : This has the following, 
possible values: 

(a) nil -- no lexical specification 

(b) a mark -- an atom = sub or super 

(c) a designator denoting the presence of the type 
definition of the concept type. 

Roles of (b) and (c) in making a lexical decision is 
elaborated in 3.1.5. Some sample CDict entries, are shown 
below: 

Example 1. concept-type= uda-4; entryft elegu)= 

(verb (vyApiMc uda-kch) nil nil) 

This particular concept type has no lexical specification or 
transfer rule associated with it. Further, it has a single 
lexical realisation in Telugu. 

Example 2. concept-type= suna-1 ; entry(telegu)= 

(verb (vin suna-kch) 

($case ([(not (^:null kriya-vish)) 

[(ch-con bola-1 ) 

(ch-con tarn 0_subjnc) 

(ch-rel karwA sampraxAna) ] ] ) ) nil) 

This one also has a single lexical realisation and has a 
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transfer rule associated with it. Section 3.1.4 contains an 
explanation of the rule. 

Example 3. concept-type= KA-0; entry (hindi ) = 

(verb nil nil sub) 

This concept-type has no realisation in hindi , but as the 
lexical specification field indicates, it may be realised 
via one of its subtypes in the concept type hierarchyC viz , 
pI-2). 

3.1.2 THE KARAK CHART 

This is a piece of data associated with every verb root 
in a language, embodying the meaning of the ver»b in some 
sense. It does so by providing detailed specifications or 
restrictions on the fillers of the semantic roles of the 
action it performs. It is a list of karak restrictions (one 
for each role eg, karta, karma etc) each of which is a 
structure of the following format: 

(<karakname> <necessity> <vibhakti> <sf-expr>) 

<karakname> : this is the name of a semantic role ,eg, 
karta . 

<necessity> : this expresses how necessary the presence of 
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this karak is on the surface string or in the CG . The 
allowed values are: in(mandatory) , d(desirable) , o(optional), 
phi(should be absent). 

<vibhakti> : this field contains the value of the vibhakti 
(possibly a list of values) taken up by the filler of this 
kafrak role, on the surface. 

<sf-expr> : the value of this slot imposes selectional con- 
straints on the filler of this karak role. This is used dif- 
ferently by the parser and the generator. The parser uses it 
to determine which karak role a word group satisfies and the 
generator uses it to ensure the semantic well-formedness of 
a CG . 


A sample karak chart is shown below (for the verb 
jowa) : 

((karwA m 1 ($type prANI)) 

(karma m 2 (or($type prANI )($type yaHwra) ($type sUAna))) 
(karana d 3 (or($type prANI )($type yaMwra)))) 

The restriction for karana states that presence of such a 
karak filler is desirable, and if present, it must be a sub- 
type of prANI or yaMwra. 
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3.1.3 THE NOUN CHART 

This piece of data is associated with every noun root 
in a language, containing information about its inherent 
properties (viz, its meaning encoded as a concept type; 
super -speci es of that concept type ; material of which it is 
composed etc) and constraints on the fillers of the noun- 
noun relations (eg, sambandh , above, below etc) which may 
be attached to it. It is essentially a structure of the fol- 
lowing description : 

(<super-type> <concept-type> <upadhi > <concept-class> 

<kriya-rels> <gen-rels> <dravya> <guna>) 

3-1.4 TRANSFER SPECIFICATION SYNTAX 

This is a tool offered to the language expert to 
ture the idiosyncraci es of a language. The syntax is as 



lows : 
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($case { C<condition> t<actionl> 

C 

. )) 

which is a one-of case stateraent, i.e., if a <cond> is 
satisfied, each of the <actn>’s following it are performed 
on the graph and the statement is exited. 

3.1.4. 1 CONDITION 


<actn2> . . . ] ) 
) 


There are three condition primitives, viz, %type, %val , 
%null. A condition is either a primitive or a logical (and, 
or, not) combination thereof. Uhen a transfer rule is bound 
to an action concept, the syntax described, has the power to 
access all its direct arguments, i.e., concepts connected to 
it via karaks , verb-verb relations etc. Similarly, for argu- 
ment concepts, all its noun-noun relations may be accessed, 
examples: 

(%type karma prANI ) expresses the restriction that the 
karma of the action concept (to which the rule is bound) 


must be animate. 
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(%val karta <vall> <val2> ...) states that the karta 
must have a concept type which is one of the specified 
<val>'s. 

kar-aNa) f-etuf-na true if in the given graph, the 
action concept has no karaNa relation attached to it. 

3. 1.4. 2 ACTION 


There are five primitive actions at present (subject to 
extension as and when concrete situations turn up) which 
have the power to handle all kinds of transfer acts in view, 
either alone or in combination. Combination is of course via 
adjacency only, i.e., actions are performed in the order 
specif i ed . 

Usage : 

(a) (ch-con <rel> <con>) pr (ch-con <con>) 

> 

<con> is a (<con-type> <con-ref>) pair for individual 
concepts and simply a <con-type> for generics. 

Ex 1. (ch-con karma xahl) alters (in place) the type 
and referent of the karma of the action concept to 
xahl and * (generic marker) respectively. If the graph 
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was : 

[ j amA ] - 

CkarwA)-> [person : sIwA] ....(3.1) 

(karina)->[xuXa] . 

with the transfer rule bound to the concept type ’’jamA”, 
it becomes: 

[ j amA ] - 

(karwA)-> [ person : s IwA ] (3.2) 

(karma)-> [xahl : * ] . 

Ex 2. (ch-con KA-3) alters the type and referent of the 
action concept itself to KA-3 and * respectively. The 
£raph in (3.2) would become: 

[KA-3 : *]- 

(karwA)-> [person: sIwA] (3.3) 

(karma)-> [xahl : * 3 . 

(b) (ch-rel <rell> <rel2>) 

Ex 1. (ch-rel karwA sampraxAna) changes (in place) the 
relation karwA (attached to the action concept) to sam- 
praxAna. The graph in (3.3) would become: 

[KA-3:*]- 

(sampraxAna)-> [person : sIwA] 

(karma) -> [xahl :* 3 . 
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(c) (del <rel>) 

Ex 1. (del karma) deletes the karma from the action con- 
cept. (3.3) would be altered to: 

[KA-3:*]- 

(karwA)-> [person: si wA] . 

(d) (ch-link <rel> <con>) 

Ex 1. (ch-link karma (dog kaiser)) changes the link 
between the karma relation and the karma argument to 
that between the karma relation and a concept whose type 
and referent are specified. Such a concept has to exist 
in the graph and the first such concept found , is used. 

If the graph is: 

[xeKa]- 

(karwA)-> [ doctor ] 

( karma) -> [ tongue ] <- (sambandh) <- [ dog : kaiser ] 
and if the rule is bound to xeKa, th new graph is : 

[xeKa]- 

(karwA)-> [ doctor ] (3.4) 

( karma) -> [ dog : kaiser ]->( sambandh) -> [ tongue ] 

(e) (add <conl> <rel> <con2>) 

Ex 1. (add (man rAm) sambandh karma) would do the fol- 


lowing to (3.4): 
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[xeKa]” 

CkarwA)“"> [doctor ] 

(karma) “ > [ dog : kaiser ] ~ 

(sambandh)“> [ tongue] 

( s ambandh ) < - [ man : r Am ] . 

(add karma sambandh (man rAm)) would have reversed the 
direction of the arrows. 

Considering the sample graph: 

[suna-l]~ 

( kar wA ) ~ > [ man : rAm ] 

(kriya~vish)“-> [ loud] 

(tam)->[wA_hE] . 

the transfer rule (example 2, 3.1) bound to "suna-1” 

($case {[(not (%null kriya~vish)) 

[(ch~con bola-1) 

(ch~con tarn O^^subjnc) 

(ch-rel karwA sampraxAna)] ]}) 
checks whether ”suna~l” has a relation called "kriya- 
vish” in the graph. If it does, then the actions are 
performed one by one. The resultant graph is: 



30 


[bola-1:*] 

(sampraxAna) -> [ man : rAm] 
(kriya~vish)-> [loud] 

( tam)-> [ 0_sub jnc ] . 

3.1.5 LEXICAL SPECIFICATION 

If the lexical specification is a mark, it pro- 
vides a relative change in strategy for lexical choice. 
Its presence implies that, for the target language in 
question, there exists a better (than the choices bound 
to itself) lexical realisation of the concept type in 
the lexical choices of the types either higher up (if 
mark = super) or lower down (mark = sub) in the concept 
type hierarchy. So, even if the field for lexical 
choices is non-empty, the type hierarchy is traversed 
first for a good choice, if nothing is available, only 
then is lexical choice field looked at. If there are no 
lexical choices either via the type hierarchy or in the 
the dictionary entry, or if none of the values in the 
dictionary entry apply, then the lexical specification 
is inspected once more to check whether the concept type 
has a type definition. If the definition is found , the 
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concept type is replaced by itCthereby expanding the 
graph) and the process of creating lexical bindings is 
continued for the new and hopefully realisable concepts 
in the expanded graph. 

Situations employing the lexical specification 
field when it has a mark (sub or super) has already been 
illustrated earlier in this chapter. To motivate the 
usage of type definitions, one could imagine the MT sys- 
tem to be in a state where the intermediate language is 
sufficiently rich,(i.e., concepts are resolved into rea- 
sonably fine shades along with type definitions) and a 
new language is being installed in the system. Even 
while the data for the new language is incompl et e (which 
will probably be the case), translation will not fail 
because any fine concept in the input (to the generator) 
CG will be expanded in terms of courser concepts which 
in turn will be lexically realisable. Also, when a con- 
cept is not realisable in a language(not because of 
incomplete data), using type definitions would be 
expedient. 

For example, supposing we are to translate from 
Marathi to Hindi and the parser generates a CG which has 
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a concept ’’SrlKand" in it. Now, the concept dictionary 
for Hindi has the following entry for the concept type 
"SrlKand” : 

(noun nil nil def), 

which states that this concept does not have any direct 
realisation, neither can it be realised by traversing 
the concept type hierarchy, but it does have a type 
definition available in the intermediate language, using 
which the generation procedure can continue. 

3.2 INPLEKENTATION 

3.2.1 TRANSFER AND LEXICAL CHOICE MODULE 

Procedure XFLC 

purpose: to create lexical binding for a concept in a graph 
input: a concept, its type, the graph where it occurs 
output: a graph with the above concept lexically bound 
algorithm: 

XFLC (con cty gr) 

1. Lookup CDict entry for cty 

2. If <xf-rule> is empty, go to 3. 


else 
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apply rule on g.r 

if con-type of con has been charified due to xfer 

go to 1 . with xf erred graph and cty = new con-type 
lex-spec> is empty, go to 4. 

if its a mark, follow it 

i.e., if mark=sub, invoke XFLC for each subtype of cty until 
a choice is made, 
ect <1 ex-choi ces> 
if it is empty then, 

.1.1 if <lex-spec> has type definition for con-type of con then 
expand gr on con and go to 1 . 
else, FAIL. 

if it has one value, ACCEPT, 
else 

try to get the appropriate value by constraint satisfaction 
4.3.1 if successful, ACCEPT 
else , go to 4.1.1 

fig. 3.2 creating lexical binding for 
concept con in graph gr . 

each ironcept (say with type c) in the graph, the 
ocedure (xfer + lex.choice or XFLC) is performed 
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(called with cty = c). Firstly, the CDict entry for c is 
looked up, if the field for xfer rule is non empty, it is 
on the graph, if this action itiodofies c itself, 
then the procedure described so far is repeated until the 
xfer rule field is found to be empty. At this stage, the 
lexical specification is looked at. If its a mark then the 
type hierarchy is invoked with it, i.e.,if mark = super 
then this procedure is called with the every supertype of 
c until a choice is found. If a choice is found, the pro- 
cess is exited, else, the field for lexical choices in the 
CDict entry for c is inspected. If the field for lexical 
choices has one value (<root> <schema>) pair) then that is 
taken to be the choice and the process is exited. If it 
has more than one value, inappropriate choices are elim- 
inated using a constraint satisfaction scheme described in 
the next section. In case none of the values in the lexi- 
cal choice field are found to be appropriate or if it is 
empty to start with, the lexical specification field is 
looked up once more to check if the type definition for 
the concept (to be bound) type is available. If it is, the 
graph is expanded on the concept and lexical bindings are 
created for the new concepts. XFLC admits failure iff none 
of the above cases apply. 
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3.2.2 TRAVERSING THE GRAPH AND CONSTRAINT SATISFACTION 

XFLC is called with the main action concept, its type 
and the graph. Through any route, the control has to come 
to 4.2 for creating a lexical choice. At this point, the 
status is that the action concept has one or more lexical 
realisations in the target language. Now, each of the con- 
cepts connected to the action concept by a relation are 
inspected. If the relation is a karak (eg, karta) , XFLC 
is applied to the argument concept and if its a verb-verb 
relation (eg, ktwa,shatri etc), the argument concept is 
pushed onto a stack (*S*) global to the procedure of 
traversal. If the action concept and the argument concept 
both have single realisations, lexical binding is created 
straightaway. For other cases ,viz, the action concept has 
one realisation and the argument concept has more than one 
realisaton or, the action concept has more than one 
realisation, conformity checking needs to be done for elim- 
inating inappropriate choices. This is done in the follow- 
ing manner: 

(a) For a lexical realisation of the action concept, 
its karak chart is invoked. 
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(b) For creating bindings for an argument concept 
(say, the karta) the relevant karak restriction is 
extracted from the karak chart, 

(c) For a realisation of the argument concept, its 
noun chart is invoked, 

(d) The s f~ expression in the extracted restriction is 
applied on the noun chart, 

(e) If (d) succeeds, the choice made in (c) is the 
correct choice for this argument concept and control goes 
to (b) with the next argument concept. If (d) fails, con- 
trol goes to (c) with the next realisation of this argu- 
ment concept . 

(f) If the lexical bindings are successfully (i.e., 
(d) succeeds) created for each karak argument connected to 
the action concept, the lexical choice made for this 
action concept in (a) is the correct choice. If any karak 
argument fails to be lexically bound, control goes to (a) 
with the next realisation of this action concept. 

Once the lexical choice of an action concept is suc- 
cessfully completed, i.e., all its karak arguments are 
lexically bound also, is inspected. If its empty, the 
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transfer component is through, else, is popped and the 
above procedure is repeated for the popped concept. If 
there is failure at any stage, i.e., the conformity check 
fails after the graph has undergone xfer, one step back- 
tracking is done. That is, the graph in its preceding 
stage of transfer is saved and in case of failure in the 
current stage, operation is resumed with the preceding 
stage. Since a verb does not exert any influence on its 
verb-verb relations, the previous steps of transfer don't 
need to be undone. As an example, one could think of a 
situation where the main verb and its immediate arguments 
are lexically bound and the graph has possibly undergone 
some transformation (say it is in state SI). Now, say the 
type hierarchy is being traversed for the choice of an 
action concept in (i.e., one of the concepts bound to 

the main verb by a verb-verb relation) and mark= super . 

\ 

Supposing the current concept type could not yield a 
choice, but did transfer the graph on the basis of the 
<xf-rule> associated with it (say, R) . Now, the next 
supertype of the action concept has to be considered and 
the rule associated with it is applied on the graph in its 
preceding state (viz, SI) of transfer ,i.e., before R was 


applied . 



3.2.3 TRAVERSING THE TYPE HIERARCHY 


In case the <lex-spec> for a concept type is a mark 
(as defined earlier) , type hierarchy is traversed. For 
each concept (action or argument), while the lexical bind- 
ing is yet to be created and the type hierarchy is being 
traversed, all its supertypes, subtypes and types- 
visi t ed-so- f ar are kept track of. These data structures 
are liquidated once a new concept needs to be lexically 
bound. They are initially empty (remain empty if the type 
hierarchy is not invoked) and are filled up in the follow- 
ing manner: 

There are four queues, global to the process of lexi- 
cal binding for a given concept (action or argument), for 
maintaining its supertypes and subtypes, viz, *NSB* 
(arg.,sub), *NSP* (arg. , super) , *VSB* (actn.,sub) , *VSP* 
(actn ., super ) . Say, lexical bindings are being created for 
an argument concept and mark=sub. Then all the subtypes 
of this concept is inserted in *NSB* (if mark was = super, 
*NSP* would be used); for each of the concept types (cty) 
in *NSB*, XFLC is called. If the <lex-spec> is a mark and 
sub once more in the process of type hierarchy traversal. 
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then the subtypes of that cty is joined to the tail of 
*NSB^ to maintain a breadth first ordering of traversal. 

Consider the following situation: supposing the con- 
cept being bound has 

Ccl) 


(c2) (c3) 


fig. Section of a dummy type hierarchy 
type c2 and <lex-spec> = super and let the <lex-spec> of 
cl = sub (i.e,, the desired lexical choice lies with c3)- 
there is a possibility of looping indefinitely unless one 
keeps track of the types visi t ed-so-f ar in the type 
hierarchy. So, each time a (new) cty is visited, it is 
recorded in a list and when the control shifts to another 
cty, if the membership test of that cty in the list 
succeeds, then it is not visited, else, it is recorded in 
the list and visited. The scheme described above for type 
hierarchy traversal is completely applicable to action 


concepts . 
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chapter 4 


THE GENERATOR 


This is the block which generates the target language 
sentence from the conceptual graph passed down by the 
transfer component. Conceptually, it can be segmented into 
three parts, essentially isomorphic with the parser but 
converse in functionality. 


1 CG FROM THE 
I XFER COMPONENT 


1 

1 GENERATOR CORE 
1 

II 

II 

II 

11 

V 

1 

TAM-> p-xf MAP 
vibhkt disamb. rules 

1 

[LIST OF 

1 GROUPS 

WORD 


1 

1 SPLITTER 

1 

11 

li 

1! 

II 

V 

TAM-> verb- form MAP 
vibhkt-> case-parsrg 

1 

[LIST OF 

1 ENTRIES 

UORD 


1 

1 MORPHOLOGICAL 

1 SYNTHESIZER 

II 

li 

11 

II 

V 

1 

LEXICON 


[TARGET LANGUAGE 
I TEXT 


fig. THE GENERATOR 
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4.1 GENERATOR CORE 

4.1.1 DATA ACCESSED 

CA)TAM table : Tense, aspect and modality are three 
features whose composite values map onto the conjugated 
forms of a verb as uniquely as desired. In other words, 
they are variables whose domains are large enough to dis- 
tinguish one verb form from the next, in a conjugated sys- 
tem. Each conjugated form is tagged by a tense-aspect- 
modality (TAM) marker, such that, given the verb root and 
the TAM, it is possible to retrieve the corresponding con- 
jugated form of the root. Functionally, the TAM identifies 
a specific application of a verb. The TAM table is a data- 
base indexed on TAM tags containing: 

(a) verb form : this is an expression which has the 
following format: 

(<form of the root verb> (<auxilliary root> <form>) 
(<aux. root> <form>) ) 
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if there are no auxilliaries for a TAM, the verb form 
is an atom which is the form of the root verb. 

ex., (duratv (un past)) this implies that the root verb 
will be in durative form and the auxilliary verb has the 
root "un” and will be in past form. 

(b) parsarg transfer rule (p-xf): in the TAM table, 
only the rule label is stored, the actual rule is a lisp 
procedure which accepts a karak chart and outputs another 
in which some of the karak restrictions have possibly 
undergone a change of content in the vibhkt and necy 
fields. The p-xf generates the application karak chart 
(TAM identifies an application, hence associated with it) 
from the language karak chart accessible from a lexical 
entry ( 3 . 1 . 1 . ( i i ) ) . 

The generator makes use of the p-xf rule label only, 
the TAM table is accessed once more by the splitter for 
the verb form. 

(B)vibhakti disambiguation rules: If a karak restric- 
tion has a list of values in the vibhakti field, some glo- 
bal (to the target language) rules are used to extract the 
appropriate vibhakti. This requires world knowledge about 
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the concept which is the filler of the karak restriction. 
Thus the concept type hierarchy needs to be invoked here. 
The rules are organised as follows: 

key: karak 

val : set of rules, arranged as clauses so as to elim- 
inate the non-appl icable values. 

eg . , key = karta 

val = [(($type manuRya) la) (($type prANI ) lb)] 
this states that if the filler for the karta role is 
a subtype of manuRya then the vibhakti to be taken up 
is ”la”, if the filler concept is not a subtype of 
manuRya but a subtype of prANI, then ”lb” is to be 
used . 

4.1.2 A TRIP UITH THE GENERATOR 

(A) A list of phrase groups are created at first from 
the CG passed down by the xfer component ( ”ng” and ”vg” are 
abbreviations for noun-group and verb-group respectively). 

Suppose, the graph passed down by the xfer component 


is : 
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[bETa-43- 

CkarwA)-> [ jUwA-1 ]“ 

(inod-adj)->[yah]->(pos)->[num:l] 

(pos)->[i^u®: 2] , 

(xeSa-aXi)->[pEra]- 

( mod- sam) <- [ flianuRya : rAm] -> epos ) - > [ nufli : 3 ] 

Cpos)->[nuin:41 , 

(kriya-vish)->[Tik]->(pos)->[num:5] 

(pos)->[num:6] 

(tam)->[0_sakawA_hE] . 


Lexical choicea have been „ade for the concepts, 
usin* then, the followina structure is generated Ctarget = 

bengali): 

a X ' 4 -^ A ftam 0 sakawA_hE) •• 

[(ve (root ha) (positn 6 ) - 

((kriya-viah ((adv Tik 5 ••)) )) v 

^ rr,«citn 2) ... (Ckrkrel (karwA-o£ * )) ) 

(ng (root juwo) (positn i'. / 

(rood-adj ((adj ei 1 ..)) ))) / 

4 . i'l rrt^citn 4) ((krkrel (xeSa-aXi-of **)) 

(ng (root pA) (positn . 

(nod-san ((ng (root rin) (positn 3) ....)))) )1 


(B) After this, the karak chart 


root 


(carried itt 
using the tain 
looked up f 


its entry shown above) is looked up. Then, 
( 0 _sakavA_hE, in this case) the TMI table is 
or getting the p-x£ rule (nornal in this case 
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so no xfer on karak chart), the rule is applied and the 
transformed karak chart is used for vibhkt assignment. If 
for any restriction, >1 vibhakti's are present, vibhkt 
disambiguation rules are invoked. For this example, the 
restriction for xeSa-aXi looks like: 

(xeSa-aXi m (7b 6) (or C$type manuRya) ($type prAN I -anga) ) ) 

The disambiguation, rule for xeSa-aXi is looked up 
and that states : if the filler of this role is human, 

vibhakti=6. Since that fails, the other value is taken up. 

Now , the structure looks like : 

[ (vg (root ha) (positn 6) (tam 0_sakawA_hE) .... ((... )) ) 

(ng (root juwo) (positn 2) .. (vibhkt la) . . ( (krkrel (....)) 

(mod-ad j ((...)) ))) 

(ng (root pA) (positn 4) ... (vibhkt 7b .. ((krkrel (..,)) 

(mod-sam ((...)))))] 


(C) Next, each word group is brought to the surface: 


[(vg (root ha) (positn 6) 


(tam 0_sakawA_hE) . 


(adv (root Tik) (positn 5) .... ((mod-adv-of ***)) ) 


(ng (root juwo) (positn 2) 


(vibhkt la)., ((krkrel (karwA-of **))) 


(adj (root ei) (positn 1) 


( (mod-ad j-of *'*))) 


(ng (root pA) (positn 4) (vibhkt 7b).. ((krkrel (xeSa-aXi-of *'*))) )> 


(ng (root rAm) (positn 3) 


((mod-sam- of *^ ) ) ) ] 
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(D) Vibhakti’s are put for the noun-noun relations 
I like mod-sam, above, below etc. They are usually fixed for 
I a target language. So, for any such relation R, in a noun 
j group Cng) if there is a value for the attribute R-of, the 

appropriate vibhakti for R is put. For mod-sam, 6 is put 
in the ng’s containing a value for mod-sam-of , i . e . , the 
one with root = rAm. 

(E) Finally, the word groups are sorted according to 
the surface ordering specified in the CG. For cases when 

^his default (corr . to the source text) ordering is not 
applicable , the transfer component imposes a new order on 
the CG on the basis of specified rules. The word groups 
are sorted here since splitting word groups creates new 
entries which are order sensitive. So the output of the 

generator is the following list of word groups (parse 
structure) : 

[(adj (root ei) (positn 1) 

(ng (root juwo) (positn 2) 

(ng (root rAm) (positn 3) 

(ng (root pA) (positn 4) . 

(adv (root Tik) (positn 5) 

(vg (root ha) (positn 6) . 


((mod- adj -of *\*)) ) 


(vibhkt la)., ((krkrel (karwA-of *»* ) ) ^ 


. (vibhkt 6) ... ((mod-sam-of ) ) ) 


(vibhkt 7b)... ((krkrel (xeSa-aXi-o^ 




((mod- adv- of *i*))) 


. . . (tam 0 sakawA hE) 



4.2 SPLITTER 


This block accepts the parse structure and generates 
a list of word entries. 

4.2.1 DATA ACCESSED 

(A) TAM->verb- f orm mapping : 4.1.1 (A) 

(B) vibhakti-> case-parsrg mapping : vibhakti is a 

language independent notion whereas case and parsarg are 

features which have language dependent values that 

together expresses the vibhakti. A section of the map for 

bengali is shown below. Uhen the mapped value is an atom, 

no parsarg is needed, else the necessary parsrgs are 

listed along with the case identifier (I, II etc) 

la --> I 
lb --> II 

3 --> (I xiye) 

7e --> (IV moXye Ueke) 

fig. Section of the map for Bengali 

The case identifier is the parameter on which the 
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oblique forms of a noun are indexed, i.e., given a noun 
root and a case marker, the relevant oblique noun form may 
be accessed. A declined form of a noun root is ,most gen- 
erally, an oblique form of the root followed by one or 
more parsrgs- which are special words having no signifi- 
cance of their own. 

4.2.2 TRIP RESUMED 


(A) Using the TAM field in each vg, the TAM table is 
looked up and the verb-form found is installed in the vg. 
For our case, the value found is: 

(inf (pAr pst-act-part 1 ) 

The splitter creates a new entry for each aux. verb 
and adds them (in the order they appear in the verb-form) 
just after the vg. Information about person, number and 
gender is repeated. 

(B) Using the vibh->case-parsrg map, if parsrg(s) are 
found for any ng, a new entry is created for each one and 
added just after the ng. Suppose an ng had vibhkt= 7e, 
since 7e maps to (IV moXye Ueke), the splitter does the 


foil owing : 
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C...(ng ....7e )..) — > (...(n ...IV...) 

(parsrg inoXye) 

(parsrg Ueke) ) 

For our example, la -> I; 6 -> IV; 7b -> III, so the 
splitter output looks like: 

[ (adj (root ei) (positn 1) ... ( (mod-ad j-of *^) ) ) 

(n (root juwo) (positn 2) ...(case I)., ((krkrel (karwA-of *i*)))>^ 

(n (root rAm) (positn 3) ....(case IV) . . . ( (mod-sam-of *^ * ) ) ) 

(n (root pA) (positn 4) ....(case 1 1 1 )....( (krkrel (xeSa-aXi-o£ *|* ) ) 
(adv (root Tik) (positn 5) .... ((mod-adv-of *i* ))) >>'-■■ 

(v (root ha) (positn 6) ....(verb-form inf) )4^ 

(v (root pAr) (verb-form pst-act-part ) )] 

4.3 MORPHOLOGICAL SYNTHESIZER 


This block accesses the lexicon , from which, using a 
word entry, the required word form may be looked up. For 
each word entry in the splitter output, a lexicon lookup 
is performed to output the wordform and thereby the target 
language sentence is generated. 

Final output: 


ei juwo rAmer pAe Tik howe pAre 
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4.3.1 STORAGE ISSUES 

(a) verbs : the conjugated system of a verb is stored 
as an array which has the same name as the verb root and 
has the following indices: 

(i) finite forms : verb-form, person , number , gender 

(ii) infinite forms : verb-form 

(b) nouns : the declined system of a noun is stored 
as an array which has the same name as the noun root and 
has the following indices: case identifier and number. 
Other lexical categories usually have no morphology. 
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chapt er- 5 


CONCLUSIONS 


5.1 SUMHING UP 


In this thesis, we have developed a language indepen- 
dent model of text synthesis in the context of machine 
translation using a transfer approach for handling 
language idiosyncraci es and have tried to keep the model 
as close as possible to the functional converse of the 
analyzer component of the translator. 

5.2 LIMITATIONS AND SCOPE FOR FUTURE WORK 


The present version of the generator does not handle 
the following identified situations : 

Ci) Generating a composite noun phrase which is a con- 
junction, disjunction or both, of noun phrases : 


CENT-'L 

— ' ' -viooS^. 

Acc. 
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for example, 

NP Np 

Rain’s brother’s wife and Mohan’s sister went to the "market . 
Composite NP 

This entails designing a device using which the language 
expert could easily express how a language handles con- 
junction and disjuction, i.e, how many times and where 
with respect to the NP’s does it put the conjunctive 
and/or disjunctive markers. Integrating this device to the 
system would take care of the situation. This could also 
be extended to compound sentences, wherein the problem of 
pronominal substitution would come in. 

(ii) Generating a concept with a graph referent: eg. Ram 
thinks Sita is cooking in the kitchen. The corresponding 
graph would be: 

[ think]- 

(agnt )-> [man : ram] 

(ob j )-> [prop : [cook]- 

Cagnt )-> [woman: sita] 
(loc)->[kitchen] . ]. 

A trivial way to do this would be as follows: 

for any concept with a graph referent, starting at 
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the innermost level, generate the sentence for the 
referent graph and put it in position with respect to the 
next outer level (surface ordering provided by the parser) 
with a sentence complementiser preceding it. This would 
hold for arbitrary levels of nesting but would probably 
not make very natural reading. There are possibly other 
and better ways of performing this task. 

(iii) Handling incomplete data: 

If relevant karak charts or noun charts are found to 
be missing at any stage, the system, at present, simply 
fails to function. An interactive mechanism for asking the 
user about the missing data ought to be incorporated. 



APPENDIX-1 


STRUCTURES FOR LEXICAL ENTRIES 


(n root 


(v root 


positn subcat gender number 
concpt sem-featur) 
positn subcat gender number 
caus-type tarn cclusts) 


(ng root positn subcat gender number 
concpt sem-featur) 


case 


person 


vibhkt 


(vg root positn subcat gender number person 
caus-type tam cclusts) 
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SAMPLE RUNS 


ic 

r 


1 3 (eenerate-sent CG8 'beng) 




THE CONCEPTUAL GRAPH : [bETa-105:*a3- 
(caus-type)->[N: *a] 

Cdesh-adhi)->[kursi:*a]->(pos)->tnum:4] 

( during )->[ cunAv-ho :*a]- 

(caus-type)->[N: 1 *a#00007 | ] 

(pos)-> [num: 1] , 

CkarwA)-> [ ummixvAr :*a]- 

(inod-adj)->[xo: *a]->(pos)-> [num: 2] 
(pos)->[nuni:3] , 

(pos)->[nu«i:5] 

Ctag)->[inain:*a] 

(tain)->tyAJJA:*a] . 

t Ik ttiC'ktictictic'k'kiciciiii'kic'k'k'k-k'k'kict'kic'k'k'k'kicicHic^icicidciciciQ'kiKiicic 

THE TRANSFER COMPONENT 

THE TRANSFORMED CG: 

[bETa-105:*a3- 

C caus-type)-> [N: *a3 

(d68h-adhi)-> [kursi : *a]->(pos )-> [num: 4] 
(during)-> [ cunAv-ho : *a]- 

(caus-type)->[N: | *a#00007| ] 
Cpos)->[num: 1 ] , 
(karwA)->[uromixvAr:*a]- 

(raod-ad j)->[xo: *a]->(pos)->[num: 2] 
(pos)-> [num: 3 ] , 

(pos)-> [num: 5] 

(tag)->[main: *a] 

( t am ) - > [ yA_UA : * a ] . 
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THE MORPH. SYNTHESIZER 
THE SENTENCE : 


nirbAcon hobAr Samay duj 

C’'* ’iftacAoyy KoiiK' sArt/viAi/ Oio/ 
****************** * y* * * J 


on prArUI ceyAre boSeCilo 

6*'" RwOl/ff flkj* eJ^M OuV €. feo ff Al cAj" Ao 


t 


[23(generate-sent CGIO ’beng) 


THE CONCEPTUAL GRAPH : [KA-l:*a3- 
Ccaus-type)->[C: *a] 
Ckarana)->[Sahax:*a]->(pos)->[num: 2 ] 
Ckarina)->[xavA:*a]->(pos)->[num:3] 
CkarwA)->[baccA: {*}]-> Cpos)-> [num: 1 ] 
Cpos)-> [num: 4 ] 

C tag) -> [main: *a] 
(tam)->[yA_jA_sakwA_hE:*a] . 

THE TRANSFER COMPONENT 


THE TRANSFORMED CG: 

[KA-l:*a]- 

t 

(caus-type)->[C: *a3 

(karana)-> [Sahax: *a3 -> (pos )-> [num: 2 3 
(karma) -> [xavA: *a3-> (pos )-> [num: 33 
(karwA)->[baccA: {* } 3->(pos)-> [num: 1 3 
(pos)->[num: 43 
(tag)->[main: *a3 
(tam)->[yA_jA_sakwA_hE:*a3 . 




THE MORPH. SYNTHESIZER 
THE SENTENCE : 


bAccAderke moXu diye oSuX KAvAno jewe pAre 


{'ha.eJ' cAo-cto^t 


fijLodJ^ dL^ t osk** dkc ********* * 


t 
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[ 3 3 (eenerate-sent CGll ’beng) 


THE CONCEPTUAL GRAPH : [bETa-102:*a]- 
Ccaus-type)->[N: *a] 

Cdesh-adhi)->[xil:*a]- 

Cinod-sani)->[ manuRya : rAm ]->(pos)->[ num : 4 ] 
(pos)->[num:5] , 

(karwA)->[dar: *a]->Cpos)->[nuni: 6] 

(pos ) -> [num: 7 ] 

C shat ri)->[KA- 10a: *a]- 

( apadaan)-> [ aXyapak : *a] -> (pos )-> [num: 1 ] 
(caus-type)->[N: | *a#00009 1 ] 
Ckarma)->[mAr:*a]->(pos)->[num:2] 

CkarwA)->[ manuRya: |rAm#00008| ] -> (gen)-> [no : *a] 
(pos )-> [num : 3 ] , 

( tag )-> [main: *a3 
(tam)->[ I 0_gayA| : *a] . 

it************************************************** 

THE TRANSFER COKPONENT 
THE TRANSFORMED CG: 

[KA-10a:*a3- 

(apadaan)->[aXyapak:*a]->(pos)->[num: 1 ] 

(caus-type)-> [N: 1 *a#00009 I ] 

(karma)-> [mAr: *a]-> (pos )->[num: 2 ] 

(karwA)-> [manuRya: | rAm# 00 00 8 l]->(gen)->[no:*a] 
(pos)->[num: 3] 

(8hatri)<-(bETa-102:*a]- 

(caus-type)-> [N: *a] 

(desh-adhi)->[xil : *a]- 

(mod-sam)-> [manuRya: rAm] ->(pos)- 

> [ num : 4 3 

(pos)->[num: 5 ] , 

(karwA)-> [dar : *a]->(pos )-> [num: 6 ] 

(pos)-> [num: 7 3 
(tag)->[main:*a] 

(tam)->[ I 0_gayA| :*a3 . 


THE MORPH. SYNTHESIZER 
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THE SENTENCE : 


oXyApaker kACe nAr Kawe Kave rAner mona Boy Duke eelo 


A RUN SHOWING OUTPUTS AT EACH STAGE 


C 4 3 (generate-sent CGI ’tel) 


THE CONCEPTUAL GRAPH : 
tKA-l:*a3- 

( apAxAna) — > [ aXlkAr I~l~2-3~4~5 : *a3~)> (pos ) ~ ^ [ nutn : 2 3 

(caus-type)->[N: *a3 

CkariRa)->[ jUwA-l:*a3->(pos)->[nuin:3 3 

(karwA)->[aparAXI-l- 2 : *a3->(pos)-> [nuro : 13 

Cpos ) -> [ num: 4 3 

(tag)-> [main: *a3 


Ctani)-> 

[ 1 0_rahA_UA | 

:*a3 

• 

relation 

with 

current 

verb 

is 

tain 

relation 

with 

current 

verb 

is 

tag 

relation 

with 

current 

verb 

is 

pos 


creating 

1 exical 

bindings 

for 

the 

karwA 

creating 

lexical 

bindings 

for 

the 

karma 

relation 

4 

with current verb 

is 

caus 

!-type 

creating 

lexical 

bindings 

for 

the 

apAxAna 


************************************************** 

THE TRANSFER COMPONENT 

THE TRANSFORMED CG : [KA-l:*a3- 

CapAxAna)->[aXikArI-l-2-3-4-5 : *a]->(pos)->[num: 2 3 

(caus-type)-> [N: *a3 

(karma)->[mAra-l:*a3- 

(inod-sam)<- [ jUwA-1 : *a3 -> (pos)->[nuin: 3 3 
(pos)->[num:43 ; 
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CkarwA)->{;aparAXI-l-2 :*a]->(pos)->[nuin: 1 ] 

Cpos)->{;nmn: 5] 

Ctafi)-> [main: *a] 

(tani)->[ |0_rahA_UAl :*a] . 


THE GENERATOR 

A LIST OF PHRASE GROUPS : 

((ng aXikAri 
2 

ni 1 
n 
8 

nil 

aXikArI-1-2-3-4-5 

nil 

C (krkrel 
(apAxAna 
(vg win 
5 

nil 

m 

a 

a 

N 

\ 0_rahA_UA | 

((karwA m 1 (and ($type BOwika) 

C$root jaUga)))) 

(karma m 2 t) 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or ($type manuRya) 

sUAna) ) ) ) 

nil))) 

(person a))) 

(ng wannu 
4 

nil 

n 

s 

nil 

niAra-l 

nil -I, » 

((Biod“sain ((ng jodu 3 nil n s nil jUwA- 


(not 


($type 


ni 1 
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((person a))))) 

(krkrel 
(karma 
(v£ win 
5 


nil 

m 

8 

a 


($root jaMga)))) 


aUAna)))) 


N 

I 0_rahA_UA | 

((karwA m 1 (and ($type BOwika) 
(karma m 2 t) 

(karana d 3 ($type B0wika_others) ) 
(apAxAna d 5 (or ($type manuRya) 


nil))) 
(person a))) 
(ng aparAXi 
1 

nil 

m 

8 

nil 

aparAXi -1-2 
nil 

((krkrel 
(karwA 
(vg win 
5 

nil 

m 

8 

a 


N 

I 0_rahA_UA | 

((icarwA m 1 (and ($type BOwika) 

($root jaUga)))) 

(karma m 2 t) 

(karana d 3 ($type BOwika_others ) ) 
(apAxAna d 5 (or ($type manuRya) 

sUAna)))) 

nil))) 

(person a))-) 

(vg win 
5 

nil 


(not 


($type 


(not 


($type 
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fjUAna ) ) ) ) 


I O^rahA UA| 

t(lcarvA-„ l (and (jtype BOwika) (not 


nil)) 

STRUCTURE AFTER VIBHAKTI'S ARE PUT : 


($root 


(kariaa in 2 t) 

parana d 3 ($type BOuika others)) 

(apAkAna d 5 (or (ttyja nanuKya) ($typ, 


((rig aXikAri 


m 

5 

aXikArI-l-2-3-4-5 

nil 

( (krkrel 
(apAxAna 
(vg win 
5 

nil 

01 

B 

a 

N 

|0_rahA_UA| 

((karwA in 1 (and ($type BOwika) (not 

(«rool jaUga)))) 

(karma in 2 t) 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or ($type manuRya) ($type 

nUAna) ))) 

((verb-type (duratv (un past))))))) 
(person a))) 

(ng wannu 
4 

nil 

n 

s , . 

2 

wAra-1 • ' 

nil 



t(wod» 0 aiB ((ng jodu 3 nil n s nil jUwA-i 

a))))) juwA 1 

(krkr«l 
(k«raa 
(vg win 

5 

nil 

n 

e 

6 
N 

|0_rahA_WAl 

((karwA^ffi 1 (and ($type BOwika) 


($root janga)))) 


nil 


Cnot 


aUAna)))) 


(karaa m Z t) 

(karana d 3 ($type BOwika_others ) ) 

(apAxAna d 5 (or ($type manuRya) C'^-typ, 


((verb-type (duratv (un past))))))) 
(peraon a))) 

(ng aparAXi 
1 

nil 


a 

1 

aparAXI-i-2 

nil 

( (krkrel 
(karvA 
(vg win 
S 


($root jaWga)))) 


nil 

tR 

« 

a 

N 

1 0_,rahA_UA| 
((karvA m 


1 (and ($type BOwika) Cnot 


aUAna ) ) ) ) 


(karwa in 2 t) 

(karana d 3 ($type BOwika_others) ) 

(apAxAna d 5 (or ($type manuRya) C^typ, 


((verb“type (duratv (un past))))))) 
(person a))) 

Cvg win 
5 



j.tlltu’i 3 ) ) ) 

nUAna) ) )) 


nil 

w 

a 

a 

N 

i 0„rahA_UA| 

CCkarwA ro 1 (and ($type BOwika) (not ($root 
(kariaa m 2 t) 

(karana d 3 ($type BOwika others) ) 

CapAxAna d 5 (or ($type manuRya) ($type 

((verb-type (duratv (un past))))))) 


STRUCTURE AFTER UORD GROUPS ARE BROUGHT TO THE SURFACE ‘ 

((ng aXlkAri 

2 

nil 

n 

« 

S 

aXikArI-1-2-3-4-5 

nil 

( (»od-®ani nil) 

(fliod-adj nil) 

(krkrel 
( apAxAna 
(vg win 
5 

nil 

m 

m 

a 

II 

|0_rahA_UA| 

((karwA*~ra 1 (and ($type BOwika) (not 

($root JrtHia)))) 

(karraa m 2 t) 

(karana d 3 ($type BOwika_others)) 
(apAxAna d 5 (or ($type manuRya) ($type 

sUAna)))) 

((verb-type (duratv (un past))))))) 
(peraon a))) 

(ng jod« 

3 

nil 



n 

a 

i-j i 1 

jUwA-l 

nil 

C Cmod-sain nil) 

Cwod-adj nil) 

( ffl0d~8A«-0f 
Cng wannu 
4 

nil 

n 

8 

2 

niAra-l 

nil 

((ttod-adj nil) 

(»od“8am nil) 

(krkrel 
(karna 
Cvft win 
5 

nil 

ffl 

a 

N 

jO_rahA_UAl 
((karwA m 
1 

(and C$type BOwika) 

(not ($root jaMga)))) 
(kariaa m 2 t) 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 
5 

(or ($type manuRya) 


(ftyp© nUAna)))) 

((verb-type 
(pereon a)))) 
(person a))) 

Cng wannu 
4 

nil 

n 

« 

2 

wAra-l 


(duratv 


(un past))))))) 



ni 1 

CCwod-adj nil) 
Cwod-oa« nil) 
Ckr kr«l 
Ckarwa 
Cvg win 

5 

nil 

0 

B 

6 


(Si'ool JaUga)))) 


«UAn«) ) ) ) 


I 0_rahA_yA| 

((karwA“® i (and ($type BOwika) (not 
(karraa a 2 t) 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or ($type manuRya) ($type 


(Cv«rb~type (duratv (un past))))))) 

(p«r«on a))) 

Cn« aparAXi 
i 

nil 


1 

aparAXI-1-2 

nil 

C(»od-san nil) 

(wod-adj nil) 

Ckrkral 
C karwA 
C¥S vin 
S 

nil 

n 

» 

a 

N 

jO_rahA_WA| 

((icarwA ra 1 (and ($type BOwika) (not 

(troot JaHga)))) 

Ckar«a a 2 t) 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or ($type manuRya) ($type 

((v#rb“type (duratv (un past))))))) 


eWArm)))) 
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{r<f*rnon a))) 

C v** win 

5 

nil 

m 

n 

tk 

N 

!0_rahA_UA| 

CCkarwA n 1 (and ($1:ype BOwika) (not ($root 

jaWga.) ) ) ) 

(karma a 2 t) 

(karana d 3 ($type BOwika_others)) 

CapAkAna d 5 (or ($type manuRya) ($type 

aWAna)))) 

{(v«rb-typ« (duratv (un past)))))) 

«t*»#ti***»**#t»»*t»t»*#»*t**»****»*»*************** 

STRUCTURE AFTER SORTING (PARSE STRUCTURE) : 


{(ng aparAKi 
I 

nil 

m 

m 

I 

aparAXI-1-2 

nil 

((mod-aaa nil) 
(mod-adj nil) 
(krkral 
(karwA 
(vg win 
S 

nil 


m 

a 

a 

N 

jO rahA_,MA| -i ^ 

((karwA m 1 (and ($type BOwika) 


(not 


($root jaJIga)))) ^ ' 

(karma m 2 t) 

(karana d 3 ($type BOwika_others ) ) 
(apAxAna d 5 (or ($type manuRya) 


($type 


aWAna ) ) ) ) 


((v«rb-typa (duratv (un past))))))) 

(paraon a))) 
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{j.fc- iiXikAri 
2 

nil 

n 

m 

b 

rtXikAr I -1-2-3-4-5 
nil 

{(Biod-«aiB nil) 
(»od-adj nil) 
(krkrel 
( mphxhna. 

(vg win 
5 

nil 

ii 

ii 

m 

M 


10 _r*hA_«A| 

(CkarwA a 1 (and ($type BOwika) 

CIroot jafiga)))) 

(karma a 2 t) 

(katana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or ($type manuRya) 


aUAna)))) 


(m 


( (verb-type 
(peraon a))) 

Jodu 


(duratv 


(un past))))))) 


3 

nil 

n 


(not 


($type 


4 


jUwA-1 
n i 1 

C(»od-fia» nil) 
(mod-adj nil) 
C mod-sam-of 
( ng wannu 
4 

nil 

n 


2 

ffiAra-l 

nil 

((ttod-adj nil) 
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(»od“«a« nil) 
(krkrel 
Ckarma 
Cvfi win 

5 

nil 

SI 

6 
A 

N 

! 0_rahA_WA 1 
CCkarvA ra 
1 


(and ($type BOwika) 

(not ($root jaMga)))) 
(kariRa a 2 t) 

(karana d 3 ($type BOwika_others) ) 
C apAxAna d 
5 


Cttyp« aUAna)))) 


(or ($type manuRya) 


((varb-type (duratv (un past))))))) 
(paraon a)))) 

Cparaon a))) 

(ng wannu 

1 

nil 

n 

a 

2 

mhrm-l 

nil 

( (ttod-adj nil) 

(ii©d-aa«i nil) 

(krkral 
(karna 
(vg win 
5 

ail 

9 

m 

i 

ji r^hA^UAI ^ ' 

((karwA""® 1 (and ($type BOwika) (not 

(Iroot jAflga) ) ) ) 

(karma m 2 t) ^ 

(karana d 3 (iStype BOwika_others)) 
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CapAxAna d 5 (or ($type manuRya) ($type 

((verb-type (duratv (un past))))))) 
(t»«rson a))) 

(vg win 
b 

nil 

■ 

A 

n 

1 0_rahA_«A 1 

((karwA si 1 (and C$type BOwika) (not ($root 

JaRga)))) 

(karna « 2 t) 

(karana d 3 Utype BOwika_others) ) 

CapAxAna d 5 (or ($type manuRya) ($type 

■UAna) ) ) ) 

CCv#rb“type (dvratv (un past))))))) 


THE SPLITTER STRUCTURE AFTER SPLITTING : 

((ng aparAXI 
I 

nil 


1 


*parAXI-l-l 

nil 

((pod-8a» nil) 
(wod-adj nil) 
Ckrkr*! 

( karwA 
(vg win 


5 

nil 

ff 


(front jafiga)))) 


a 

N 

jO rahA_UA| r.^ + 

((karwA a. 1 (and ($type BOwika) (not 


(karpa in 2 t) .. . 

(karana d 3 ($type BOwika_others) ) 
(apAxAna d 5 (or (f type manuRya) 


(ftype 


aUAna) ) ) ) 
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{Cv«rb-typ 0 (duratv 
CjiB'iaon «)3) 

Cf.it aXikAri 
2 

nl 1 

n 


(un past))))))) 


S 

aJtikArl 

nil 

( ( »od-g«ai nil ) 

(pod-adj nil) 

Ckrkrtl 
(apAitAna 
{vfi win 
5 

nil 

m 

m 

m 

N 

|0_r«hA,«AJ 

(CkarwA « 1 (and ($type BOwika) (not 

Ctroot 

(k*r»a a 2 t) 

(karana d 3 (ftype BOwika_others) ) 
(apkxkna d 5 (or C$type manuRya) ($type 

■UAna) ))) 

((v«rb“typ« (duratv (un past))))))) 
(p«raon a))) 

(ng Jodu 
3 

nil 

n 

a 

$ 

jUwk-l 
rii I 

( (a©d-B*» nil ) 

(wod-adj nil) 

{«od-«a»-of 
(ng wanna 

1 

nil 

n 

• 

2 

aAra-l 



“ 70 - 


( (verb- 
Cf»eraon a))') 
(tift rtXikAri 
2 

nil 


type 


Cduratv (un past))))))) 


n 

a 


S 

«KikArI-i-2-3-4.5 

nil 

( (»od-«aiB nil) 
(»od-adj nil) 
(krkrel 
(apAxAna 
(vg win 


S 

ni 1 
m 
« 

« 

n 

I O^rahA^UAI 

(front j*l1ga)))) m 1 (and (ftype BOwika) (not 

Ckaraa a 2 t) 

Ckarana d 3 (ftype BOwika others)) 
.UAn.)))) CpAxAn. d 5 (or C*type manuRya) (ftype 

((verb-type (duratv (un past))))))) 

(peraon «))) 

(n« jodu 
J 

nil 

n 

a 

t> 

jywA-i 

nil 

( (»©d“«Aa nil) 

(»od-«dJ nil) 

(imod-aaia-of 

(ng wanna 

4 

nil 

n 

» 

2 

»Ara-l 
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nil 

C(iRod-adj nil) 
(ttodj-aaa nil) 
Ckrkrel 
(k*raa 
Cvg win 


S 

nil 


« 

a 

H 

|0_rahA_UA| 

((karwA n 
1 

(and ($type BOwika) 

(not ($root jaHga)))) 
Ckarma a 2 t) 

(karana d 3 C$type BOwika others I'l 
C apAxAna d ^ 

5 


CItypa mUAnm ) ) ) ) 


(or ($type inanuRya) 


(Cvarb-type (duratv (un past)))))')', 
(paraon a)))) 

Cparaon a))) 

Cn« wannu 

1 

nil 

n 

m 

2 

wAra-l 

nil 

CC»Pd-«dJ nil) 

( nil) 

(krkr •! 

(karwa 
(vg yin 
S 

nil 

m 

m 

m 

N 

j O^rahA^llA j 

((karwA m 1 (and ($type BOwika) (not 


Hr 001 



Ckarei* nit) 

i):h.At)n ($type raanuRya) ($type 

CCv#rb-typ« (duratv (un oast '» '» 't ^ 'i ^ 

Cje-fnon •))) '■ 

( V win 

S 

n 1 J 
m 
m 
* 

U 

10 tmhh UAI 

((k.fwA*. 1 („d 

( k«t iB« m 2 %) 

Ckarana d 3 (#typ. BOwika others)) 

Imphuknm 4 5 (or (ftype manuRya) ($type 

C(vft,-iyp, dwratv) (verb-type (duratv (un 

Cv un nil nii » e * ail nn ((verb-type 


Jafifia)))) 


•M^*} ) ) ) 

p*tt ) ) 3 ) ) 

>••133 3 3 


f#***f*»*»**#i#i»tt»t*t«*#****t************* 


TIEnOtrH. SYWTHFSIZEI 


T8i SEiTENCI t 

•p*rA 3 li 1*31 i klii 3 nunci Jodw wannuni wllttU unnADu 

J,/ iUjAA*.a!ciJ 

t CC2 *t*i3 

m vmci^iniiM mAvn t 

f *a3 

{Krt» fr<i*)->fCad|-I !»ii 3 ->Cpo» 3">£»«®'3 3 

wA)->|cara“!- 2 - 3 -l-Ss*aJ->Cpos)->[nuiB:l] 

{ j. ■m ) > f tnii* J 4 I , . 

( 1 1*4‘ ) '• > f }«i* 1 r» I * • 3 
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l-mArl l!*a3->(pos)->tnuin:2]. 




1«|: iF7.wsrEp COnPOiENT 
THE irAWSrOEffEO CG : tpA-2:*a3- 

Ck«f wA3->|C*dI-I ;»a3->(po8).>j-jjyj„.3j 

(i*i»P|*ra*An*5->Uor«-l-2-3-4-5;»aJ->(pos)->rnuin.n 

Ci*oit ) - > I n«»: I J ^ ^ >[nuin.l3 

( » i»« )' >tii«in{«a3 
C 1 *•)->{ yAs 

C*«Sa-4iXi J->{«l»ArI-li**3->(pos)->[nmn:2]. 




;*t2k**t******** 


THE no»ril. Sff4T«ESI2ER 


THE SEIiTEWCE s 

*oVnis«iki alfiArulo Juvv* xoVrikilfxi 

/** ^ l| # 1^411 %%#/# 


APPENDIX-2 


SAMPLE RUN OF THE PARSER FOR THE EXAMPLE #4 IN APPENDIX-1 




THE MORPH. ANALYZER 


(setq *sent* ’(aparAXi aXikArl se jUwA KA rahA UA)) 

(setq *lex* 

’(((n aparAXi nil c m s d aparAXI-1-2 manuRya ((nclusts aparAXI- 


1 - 2 ))) 


(n aparAXi nil c m s o aparAXI-1-2 manuRya ((nclusts aparAXI- 


1 - 2 ))) 

(n aparAXi nil c m p d aparAXI-1-2 manuRya ((nclusts aparAXI- 

1 - 2 )))) 


((n 

aXikArl 

ni 1 

c 

m 

s 

d 

aX.ikArI-l-2-3-4-5 

nil 

C (nclusts 

aXikArI-1-2- 

3-4-5))) 









(n 

aXikArl 

nil 

c 

m 

P 

d 

aXikArI-1-2-3-4-5 

nil 

( (nclusts 

aXikArI-1-2- 

3-4-5))) 




- 





(n 

aXikArl 

nil 

c 

m 

s 

o 

aXikArI-1-2-3-4-5 

nil 

( (nclusts 


aXikArI-l-2-3-4-'5) )) ) 

((parsrg se nil any any any nil)) 
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((n jUwA 
nil 
c 

m 

P 

d 

jUwA-1 

nil 

((nclusts jUwA-1)))) 

((v KA nil via m s any n 0 (KA-1-2-3) nil) 

Cv KA nil via m p any n 0 (KA-1-2-3) nil) 

(v KA nil via £ s any n 0 (KA-1-2-3) nil) 

(v KA nil via f p any n 0 (KA-1-2-3) nil)) 

((v raha nil intransitive m s u normal yA (raha-kf) nil) 

(v raha nil intransitive m s m normal yA (raha-kf) nil) 

(v raha nil intransitive m s a normal yA (raha-kf) nil)) 

((v UA nil aux m s all normal all (hE-k£) nil)) 

((fullstop nil nil)) 

((fullstop nil nil)))) 


THE GROUPER 


(setq *lwe* 
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'((Cnfi aparAXI 
1 

c 

m 

a 

($enuxn 12) 

aparAXI~l-2 

manuRya 

((parsre d) (person nil) (nclusts aparAXI -1-2 )) ) 
Cng aparAXI 

1 

c 

m 

P 

($enuin 1 2) 

aparAXI - 1-2 
inanuRya 

((parsrg d) (person nil) (nclusts aparAXI-1-2) ) ) ) 
((ng aXikArl 

2 

c 

m 

s 


C$annm 3 5) 



77 " 


aXikArI-1-2-3-4-5 

nil 

((parsrg se) (person nil) Cn^)**** 
((ng jUwA 
3 
c 

m 


P 


($enuin 1 2) 

jUwA-1 

nil 

((parsrg d) 

(person nil) 

(nclusts jUwA- 1 )))) 

CCve KA 4 via „ 3 a„y IO_r.hA.U»| 
((fullstop nil nil)) 

((fullstop nil nil)))) 


I f I < 


^ » X * 


'****,,,, 

* ^ ♦ f # ; 


HE PARSER 


5E CONCEPTUAL GRAPH : 


iCA-l:*a]- 

(apAxAna)-> [ aXikAr I -i~2~3«a 

'll « 




'©•} 
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(caus-type)-> [N: *a] 

(karma) ->[ jUwA-1 : *a]->(pos)->[num: 3] 
CkarwA)-> [aparAXI-1-2 : *a] -> (pos)-> [num: 1 ] 
Cpos)-> [num: 4 ] 

Ctag)->[main: *a] 

(tam)->[ 10_rahA_UAl :*a3. 


CONCEPTUAL GRAPHS. 


Conceptual graphs are bipartite graphs. There are two types of nodes 
called as concepts and relations. The concepts represent entities, a ttributes,states 
and events and the relations represent the interlinking of these concepts. The 
mosaic of percepts that gets formed on the sensory excitation recieved by eyes, 
when a cat is sitting on a mat can be described by the following conceptual graph: 

tcat3*-(agent)i-CsiU-»Cloc)-»DnatL 

The graph expresses, "Some cat is agent of some action of sitting and the 
location of the act of sitting is some mat". In the linear notation of representing 
the conceptual graphs, the concepts are encased in square brackets while the 
relations are encased in parenthesis. The arcs which join the relations and the 
concepts are represented by arrows. 

In general a concept has two fields, a type field and a referent field. In the 
above example cat,mat and sit are the types of three different concepts. The 
referent field of a concept is analogous to the variables used in symbolic logic. 
The referent can be of many types. A generic referent talks about an unspecified 
individual, analogous to the existantially quantified variables in symbolic logic. An 
instance of an individual is represented by an indii^idual referent, which can be an 
identification number. A context is represented by a special type of concept: 
PROPOSITION, the referent of this concept can be a set of graphs. This set of 
graphs is said to occur in the context of the concept of type PROPOSITION. 

A relation in general has n arcs. We call the relation as an n-adic relation. 
Each of the arcs of the relation is connected to a concept. Relation has only a 
type label. A relation in conceptual graphs can be viewed as an n-adic predicate in 
symbolic logic. 

A hierarchy of concept types, which defines the relationships between 
concepts at different levels of generality, is called as the type hierarchy. It 
defines e partial ordering over the set of type labels . As an example the type 



elephant can be called as a subtype of type animal, which can be represented by 
elephant ^ animal. 


Every possible combination of concept nodes and relation nodes which are 
interlinked may not make sense. For example following graph is perfectly possible 
but not sensible. 


tsle^l -+(agent) -fCictea] -ftcolor) . 

To avoid such a nonsensical information, certain selectional constraints are 
essential on the permissible combination of concepts and relations. To distinguish 
the meaningful graphs that represent real or possible situations in the external 
world, certain graphs are declared to be canonical. New graphs may become 
canonical by perceptions, insights, or the formation rules. The way of deriving a 
new canonical graph from other canonical graphs by the rules of formation, is 
referred to as the process of canonical der illation. 

The transfer component of the generator performs certain operations on 
conceptual graphs, in order to handle the idiosyncraoies of a praticular language. 
These operation may not pertain to the selectional constraints. They are strictly 
for the purpose of modification of conceptual graphs for translation purpose. 
That is to say that, these operations do not obey the canonical rules of formation 
of conceptual graphs. 

Conceptual graphs allow to define new types of concepts in form of a graph 
of more primitive types of concepts. This is parallel to the notion of explaining 
more complex actions or entities in terms of primitives, in any natural language. 
The relations also can be defined in terms of other graphs. This mechanism of is 
called as type definition mechanism. 
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GLOSSARY 


Action Concept : 

A concept that embodies an action, eg, KA-2, which embo- 
dies a certain class (captured by the number 2) of 
ingestion. 

Argument Concept : 

A concept that embodies an object or an entity 
which can be an argument of an action or may even modify 
an action or an entity, eg, jUwA-1, which embodies a 
certain class of footwear. 

Akankshya: 

This expresses the semantic demand of a word group 
for its arguments. 

Karak: 

These are the semantic roles which are filled up by 
the arguments of an action, eg, 
karwA-- agent of the action 
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karma — object of the action 
karaNa — instrument of the action 

xeSa~aXikarana location of occurence of the action 
kAla-aXikarana — time of occurence of the action. 

Tam : 

The tense, aspect and modality features of a verb 
form are rolled into one to compose the "tarn” marker. 
Given a verb root and a tam marker, it is possible to 
access the corresponding conjugated verb form. 

Yogyata: 

This expresses the selectional constraints of a 
word group in order to satisfy the demands of another. 
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